Identifying  Potential  Type  Confusion  in  Authenticated  Messages 


Catherine  Meadows 
Code  5543 

Naval  Research  Laboratory 
Washington,  DC  20375 
meadows  @  itd.nrl.navy.mil 


Abstract 

A  type  confusion  attack  is  one  in  which  a  principal  ac¬ 
cepts  data  of  one  type  as  data  of  another.  Although  it  has 
been  shown  by  Heather  et  al.  that  there  are  simple  for¬ 
matting  conventions  that  will  guarantee  that  protocols 
are  free  from  simple  type  confusions  in  which  fields  of 
one  type  are  substituted  for  fields  of  another,  it  is  not 
clear  how  well  they  defend  against  more  complex  at¬ 
tacks,  or  against  attacks  arising  from  interaction  with 
protocols  that  are  formatted  according  to  different  con¬ 
ventions.  In  this  paper  we  show  how  type  confusion 
attacks  can  arise  in  realistic  situations  even  when  the 
types  are  explicitly  defined  in  at  least  some  of  the  mes¬ 
sages,  using  examples  from  our  recent  analysis  of  the 
Group  Domain  of  Interpretation  Protocol.  We  then  de¬ 
velop  a  formal  model  of  types  that  can  capture  potential 
ambiguity  of  type  notation,  and  outline  a  procedure  for 
determining  whether  or  not  the  types  of  two  messages 
can  be  confused.  We  also  discuss  some  open  issues. 

1  Introduction 

Type  confusion  attacks  arise  when  it  is  possible  to  con¬ 
fuse  a  message  containing  data  of  one  type  with  a  mes¬ 
sage  containing  data  of  another.  The  most  simple  type 
confusion  attacks  are  ones  in  which  fields  of  one  type 
are  confused  with  fields  of  another  type,  such  as  is  de¬ 
scribed  in  [7],  but  it  is  also  possible  to  imagine  attacks 
in  which  fields  of  one  type  are  confused  with  a  con¬ 
catenation  of  fields  of  another  type,  as  is  described  by 
Snekkenes  in  [8],  or  even  attacks  in  which  pieces  of 
fields  of  one  type  are  confused  with  pieces  of  fields  of 
other  types. 

Simple  type  confusion  attacks,  in  which  a  field  of  one 
type  is  confused  with  a  field  of  another  type,  are  easy 
to  prevent  by  including  type  labels  (tags)  for  all  data 
and  authenticating  labels  as  well  as  data.  This  has  been 


shown  by  Heather  et  al.  [4],  in  which  it  is  proved  that, 
assuming  a  Dolev-Yao-type  model  of  a  cryptographic 
protocol  and  intruder,  it  is  possible  to  prevent  such  sim¬ 
ple  type  confusion  attacks  by  the  use  of  this  technique. 
However,  it  is  not  been  shown  that  this  technique  will 
work  for  more  complex  type  confusion  attacks,  in  which 
tags  may  be  confused  with  data,  and  terms  or  pieces 
of  terms  of  one  type  may  be  confused  with  concatena¬ 
tions  of  terms  of  several  other  types.1  More  importantly, 
though,  although  a  tagging  technique  may  work  within 
a  single  protocol  in  which  the  technique  is  followed  for 
all  authenticated  messages,  it  does  not  prevent  type  con¬ 
fusion  of  a  protocol  that  uses  the  technique  with  a  pro¬ 
tocol  that  does  not  use  the  technique,  but  that  does  use 
the  same  authentication  keys.  Since  it  is  not  uncommon 
for  master  keys  (especially  public  keys)  to  be  used  with 
more  than  one  protocol,  it  may  be  necessary  to  develop 
other  means  for  determining  whether  or  not  type  confu¬ 
sion  is  possible.  In  this  paper  we  explore  these  issues 
further,  and  describe  a  procedure  for  detecting  the  pos¬ 
sibility  of  the  more  complex  varieties  of  type  confusion. 

The  remainder  of  this  paper  is  organized  as  follows. 
In  order  to  motivate  our  work,  in  Section  Two,  we  give  a 
brief  account  of  a  complex  type  confusion  flaw  that  was 
recently  found  during  an  analysis  of  the  Group  Domain 
of  Authentication  Protocol,  a  secure  multicast  protocol 
being  developed  by  the  Internet  Engineering  Task  Force. 
In  Section  Three  we  give  a  formal  model  for  the  use  of 
types  in  protocols  that  takes  into  account  possible  type 
ambiguity.  In  Section  Four  we  describe  various  tech¬ 
niques  for  constructing  the  artifacts  that  will  be  used  in 
our  procedure.  In  Section  Five  we  give  a  procedure  for 
determining  whether  it  is  possible  to  confuse  the  type  of 
two  messages.  In  Section  Six  we  illustrate  our  proce¬ 
dure  by  showing  how  it  could  be  applied  to  a  simplified 
version  of  GDOI.  In  Section  Seven  we  conclude  the  pa- 

1  We  believe  that  it  could,  however,  if  the  type  tags  were  augmented 
with  tags  giving  the  length  of  the  tagged  field,  as  is  done  in  many 
implementations  of  cryptographic  protocols. 
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2  The  GDOI  Attack 

In  this  section  we  describe  a  type  flaw  attack  that  was 
found  on  an  early  version  of  the  GDOI  protocol. 

The  Group  Domain  of  Interpretation  protocol  (GDOI  ) 
[2],  is  a  group  key  distribution  protocol  that  is  undergo¬ 
ing  the  IETF  standardization  process.  It  is  built  on  top 
of  the  ISAKMP  [6]  and  IKE  [3]  protocols  for  key  man¬ 
agement,  which  imposes  some  constraints  on  the  way  in 
which  it  is  formatted.  GDOI  consists  of  two  parts.  In 
the  first  part,  called  the  Groupkey  Pull  Protocol,  a  prin¬ 
cipal  joins  the  group  and  gets  a  group  key-encryption- 
key  from  the  Group  Controller/Key  Distributor  (GCKS) 
in  a  handshake  protocol  protected  by  a  pairwise  key  that 
was  originally  exchanged  using  IKE.  In  the  second  part, 
called  the  Groupkey  Push  Message,  the  GCKS  sends 
out  new  traffic  encryption  keys  protected  by  the  GCKS’s 
digital  signature  and  the  key  encryption  key. 

Both  pieces  of  the  protocol  can  make  use  of  digital 
signatures.  The  Groupkey  Pull  Protocol  offers  the  op¬ 
tion  of  including  a  Proof-of-Possession  field,  in  which 
either  or  both  parties  can  prove  possession  of  a  public 
key  by  signing  the  concatenation  of  a  nonce  NA  gener¬ 
ated  by  the  group  member  and  a  nonce  NB  generated 
by  the  GCKS.  This  can  be  used  to  show  linkage  with  a 
certificate  containing  the  public  key,  and  hence  the  pos¬ 
session  of  any  identity  or  privileges  stored  in  that  certifi¬ 
cate. 

As  for  the  Groupkey  Push  Message,  it  is  first  signed 
by  the  GCKS’s  private  key,  and  then  encrypted  with  the 
key  encryption  key.  The  signed  information  includes  a 
header  HDR,  (which  is  sent  in  the  clear),  and  contains, 
besides  the  header,  the  following  information: 

1.  a  sequence  number  SEQ  (to  guard  against  replay 
attacks); 

2.  a  security  association  SA; 

3.  a  Key  Download  payload  KD,  and; 

4.  an  optional  certificate,  CERT. 

According  to  the  conventions  of  ISAKMP,  HDR  must 
begin  with  a  random  or  pseudo-random  number.  In  pair¬ 
wise  protocols,  this  is  jointly  generated  by  both  parties, 
but  in  GDOI,  since  the  message  must  go  from  one  to 
many,  this  is  not  practical.  Thus,  the  number  is  gener¬ 
ated  by  the  GCKS.  Similarly,  it  is  likely  that  the  Key 
Download  message  will  end  in  a  random  number:  a  key. 
Thus,  it  is  reasonable  to  assume  that  the  signed  part  of  a 


Groupkey  Push  Message  both  begins  and  ends  in  a  ran¬ 
dom  number. 

We  found  two  type  confusion  attacks.  In  both,  we  as¬ 
sume  that  the  same  private  key  is  used  by  the  GCKS  to 
sign  POPs  and  Groupkey  Push  Messages.  In  the  first 
of  these,  we  assume  a  dishonest  group  member  who 
wants  to  pass  off  a  signed  POP  from  the  GCKS  as  a 
Groupkey  Push  Message.  To  do  this,  we  assume  that  she 
creates  a  fake  plaintext  Groupkey  Push  Message  GPM, 
which  is  missing  only  the  last  (random)  part  of  the  Key 
Download  Payload.  She  then  initiates  an  instance  of  the 
Groupkey  Pull  Protocol  with  the  GCKS,  but  in  place  of 
her  nonce,  she  sends  GPM.  The  GCKS  responds  by  ap¬ 
pending  its  nonce  NB  and  signing  it,  to  create  a  signed 
(GPM.NB).  If  NB  is  of  the  right  size,  this  will  look  like 
a  signed  Groupkey  Push  Message.  The  group  member 
can  then  encrypt  it  with  the  key  encryption  key  (which 
she  will  know,  being  a  group  member)  and  send  it  out  to 
the  entire  group. 

The  second  attack  requires  a  few  more  assumptions. 
We  assume  that  there  is  a  group  member  A  who  can  also 
act  as  a  GCKS,  and  that  the  pairwise  key  between  A  and 
another  GCKS,  B,  is  stolen,  but  that  B's  private  key  is 
still  secure.  Suppose  that  A,  acting  as  a  group  mem¬ 
ber,  initiates  a  Groupkey  Pull  Protocol  with  B.  Since 
their  pairwise  key  is  stolen,  it  is  possible  for  an  intruder 
I  to  insert  a  fake  nonce  for  B’s  nonce  NB.  The  nonce 
he  inserts  is  a  fake  Groupkey  Push  Message  GPM’  that 
it  is  complete  except  for  a  prefix  of  the  header  consist¬ 
ing  of  all  or  part  of  the  random  number  beginning  the 
header.  A  then  signs  (NA.GPM’),  which,  if  NA  is  of  the 
right  length,  will  look  like  the  signed  part  of  a  Group- 
key  Push  Message.  The  intruder  can  then  find  out  the 
key  encryption  key  from  the  completed  Groupkey  Pull 
Protocol  and  use  it  to  encrypt  the  resulting  (NA.GPM’) 
to  create  a  convincing  fake  Groupkey  Push  Message. 

Fortunately,  the  fix  was  simple.  Although  GDOI  was 
constrained  by  the  formatting  required  by  ISAKMP,  this 
was  not  the  case  for  the  information  that  was  signed 
within  GDOI.  Thus,  the  protocol  was  modified  so  that, 
whenever  a  message  was  signed  within  GDOI,  informa¬ 
tion  was  prepended  saying  what  the  purpose  was  (e.g. 
a  member’s  POP,  or  a  Groupkey  Push  Message).  This 
eliminated  the  type  confusion  attacks. 

There  are  several  things  to  note  here.  The  first  is  that 
existing  protocol  analysis  tools  are  not  very  good  at  find¬ 
ing  these  types  of  attacks.  Most  assume  that  some  sort 
of  strong  typing  is  already  implemented.  Even  when 
this  is  not  the  case,  the  ability  to  handle  the  various 
combinations  that  arise  is  somewhat  limited.  For  ex¬ 
ample,  we  found  the  second,  less  feasible,  attack  auto¬ 
matically  with  the  NRL  Protocol  Analyzer,  but  the  tool 


could  not  have  found  the  first  attack,  since  the  ability 
to  model  it  requires  the  ability  to  model  the  associativ¬ 
ity  of  concatenation,  which  the  NRL  Protocol  Analyzer 
lacks.  Moreover,  type  confusion  attacks  do  not  require  a 
perfect  matching  between  fields  of  different  types.  For 
example,  in  order  for  the  second  attack  to  succeed,  it 
is  not  necessary  for  NA  to  be  the  same  size  as  the  ran¬ 
dom  number  beginning  the  header,  only  that  it  be  no 
longer  than  that  number.  Again,  this  is  something  that  is 
not  within  the  capacity  of  most  crypto  protocol  analysis 
tools.  Finally,  most  crypto  protocol  analysis  tools  are 
not  equipped  for  probabilistic  analysis,  so  they  would 
not  be  able  to  find  cases  in  which,  although  type  con¬ 
fusion  would  not  be  possible  every  time,  it  would  occur 
with  a  high  enough  probability  to  be  a  concern. 

The  other  thing  to  note  is  that,  as  we  said  before,  even 
though  it  is  possible  to  construct  techniques  that  can  be 
used  to  guarantee  that  protocols  will  not  interact  inse¬ 
curely  with  other  protocols  that  are  formatted  using  the 
same  technique,  it  does  not  mean  that  they  will  not  inter¬ 
act  insecurely  with  protocols  that  were  formatted  using 
different  techniques,  especially  if,  in  the  case  of  GDOI’s 
use  of  ISAKMP,  the  protocol  wound  up  being  used  dif¬ 
ferently  than  it  was  originally  intended  (for  one-to-many 
instead  of  pairwise  communication).  Indeed,  this  is  the 
result  one  would  expect  given  previous  results  on  proto¬ 
col  interaction  [5,  1],  Since  it  is  to  be  expected  that  dif¬ 
ferent  protocols  will  often  use  the  same  keys,  it  seems 
prudent  to  investigate  to  what  extent  an  authenticated 
message  from  one  protocol  could  be  confused  with  an 
authenticated  message  from  another,  and  to  what  extent 
this  could  be  exploited  by  a  hostile  intruder.  The  rest  of 
this  paper  will  be  devoted  to  the  discussion  of  a  proce¬ 
dure  for  doing  so. 

3  The  Model 

In  this  section  we  will  describe  the  model  that  underlies 
our  procedure.  It  is  motivated  by  the  fact  that  differ¬ 
ent  principals  may  have  different  capacities  for  checking 
types  of  messages  and  fields  in  messages.  Some  infor¬ 
mation,  like  the  length  of  the  field,  may  be  checkable  by 
anybody.  Other  information,  like  whether  or  not  a  field 
is  a  random  number  generated  by  a  principal,  or  a  se¬ 
cret  key  belonging  to  a  principal,  will  only  be  checkable 
by  the  principal  who  generated  the  random  number  in 
the  first  case,  and  by  the  possessor(s)  of  the  secret  key 
in  the  second  place.  In  order  to  do  this,  we  need  to  de¬ 
velop  a  theory  of  types  that  take  differing  capacities  for 
checking  types  into  account. 

We  assume  an  environment  consisting  of  principals 


who  possess  information  and  can  check  properties  of 
data  based  on  that  information.  Some  information  is 
public  and  is  shared  by  all  principals.  Other  informa¬ 
tion  may  belong  to  only  one  or  a  few  principals. 

Definition  3.1  A  field  is  a  sequence  of  bits.  We  let  i 
denote  the  empty  field.  If  x  and  y  are  two  fields,  we  let 
x  1 1  y  denote  the  concatenation  ofx  and  y.  Ifx  and  y  are 
two  lists  of  fields,  then  we  let  appendix,  y)  denote  the 
list  obtained  by  appending  y  to  x. 

Definition  3.2  A  type  is  a  set  of  fields,  which  may  or 
may  not  have  a  probability  distribution  attached.  If  P 
is  a  principal,  then  a  type  local  to  P  is  a  type  such  that 
membership  in  that  type  is  checkable  by  P.  A  public  type 
is  one  whose  membership  is  checkable  by  all  principals. 
If  G  is  a  group  of  principals,  then  a  type  private  to  G  is 
a  type  such  that  membership  in  that  type  is  checkable  by 
the  members  ofG  and  only  the  members  ofG. 

Examples  of  a  public  type  would  be  all  strings  of 
length  256,  the  string  “key,”  or  well-formed  IP  ad¬ 
dresses.  Examples  of  private  types  would  be  a  random 
nonce  generated  by  a  principal  (private  to  that  principal) 
a  principal's  private  signature  key  (private  to  that  princi¬ 
pal),  and  a  secret  key  shared  by  Alice  and  Bob  (private 
to  Alice  and  Bob,  and  perhaps  the  server  that  generated 
the  key,  if  one  exists).  Note  that  a  private  type  is  not  nec¬ 
essarily  secret;  all  that  is  required  is  that  only  members 
of  the  group  to  whom  the  type  is  private  have  a  guaran¬ 
teed  means  of  checking  whether  or  not  a  field  belongs  to 
that  type.  As  in  the  case  of  the  random  number  gener¬ 
ated  by  a  principal,  other  principals  may  have  been  told 
that  a  field  belongs  to  the  type,  but  they  do  not  have  a 
reliable  means  of  verifying  this. 

The  decision  as  to  whether  or  not  a  type  is  private  or 
public  may  also  depend  upon  the  protocol  in  which  it 
is  used  and  the  properties  that  are  being  proved  about 
the  protocol.  For  example,  to  verify  the  security  of  a 
protocol  that  uses  public  keys  to  distribute  master  keys, 
we  may  want  to  assume  that  a  principal’s  public  key  is 
a  public  type,  while  if  the  purpose  of  the  protocol  is  to 
validate  a  principal’s  public  key,  we  may  want  to  assume 
that  the  type  is  private  to  that  principal  and  some  certi¬ 
fication  authority.  If  the  purpose  of  the  protocol  is  to 
distribute  the  public  key  to  the  principal,  we  may  want 
to  assume  that  the  type  is  private  to  the  certification  au¬ 
thority  alone. 

Our  use  of  public  and  local  types  is  motivated  as  fol¬ 
lows.  Suppose  that  an  intruder  wants  to  fool  Bob  into 
accepting  an  authenticated  message  M  from  a  principal 
Alice  as  an  authenticated  message  N  from  Alice.  Since 
M  is  generated  by  Alice,  it  will  consist  of  types  local  to 


her.  Thus,  for  example,  if  M  is  supposed  to  contain  a 
field  generated  by  Alice  it  will  be  a  field  generated  by 
her,  but  if  it  is  supposed  to  contain  a  field  generated  by 
another  party,  Alice  may  only  be  able  to  check  the  pub- 
lically  available  information  such  as  the  formatting  of 
that  field  before  deciding  to  include  it  in  the  message. 
Likewise,  if  Bob  is  verifying  a  message  purporting  to  be 
N,  he  will  only  be  able  to  check  for  the  types  local  to 
himself.  Thus,  our  goal  is  to  be  able  to  check  whether 
or  not  a  message  built  from  types  local  to  Alice  can  be 
confused  with  another  message  built  from  types  local  to 
Bob,  and  from  there,  to  determine  if  an  intruder  is  able 
to  take  advantage  of  this  to  fool  Bob  into  producing  a 
message  that  can  masquerade  as  one  from  Alice. 

We  do  not  attempt  to  give  a  complete  model  of  an  in¬ 
truder  in  this  paper,  but  we  do  need  to  have  at  at  least 
some  idea  of  what  types  mean  from  the  point  of  view 
of  the  intruder  to  help  us  in  computing  the  probability 
of  an  intruder’s  producing  type  confusion  attacks.  In 
particular,  we  want  to  determine  the  probability  that  the 
intruder  can  produce  (or  force  the  protocol  to  produce) 
a  field  of  one  type  that  also  belongs  to  another  type.  Es¬ 
sentially,  there  are  two  questions  of  interest  to  an  in¬ 
truder:  given  a  type,  can  it  control  what  field  of  that  type 
is  sent  in  a  message,  and  given  a  type,  will  any  arbitrary 
member  of  that  type  be  accepted  by  a  principal,  or  will 
a  member  be  accepted  only  with  a  certain  probability. 

Definition  3.3  We  say  that  a  type  is  under  the  control  of 
the  intruder  if  there  is  no  probability  distribution  associ¬ 
ated  with  it.  We  say  that  a  type  is  probabilistic  if  there  a 
a  probability  distribution  associated  with  it.  We  say  that 
a  probabilistic  type  local  to  a  principal  A  is  under  the 
control  of  A  if  the  probability  of  A  accepting  afield  as 
a  member  of  X  is  given  by  the  probability  distribution 
associated  with  X. 

The  idea  behind  probabilistic  types  and  types  under 
control  of  the  intruder  is  that  the  intruder  can  choose 
what  member  of  a  type  can  be  used  in  a  message  if  it 
is  under  its  control,  but  for  probabilistic  types  the  field 
used  will  be  chosen  according  to  the  probability  distri¬ 
bution  associated  with  the  type.  On  the  other  hand,  if 
a  type  is  not  under  the  control  of  a  principal  A ,  then  A 
will  accept  any  member  of  that  type,  while  if  the  type 
is  under  the  control  of  A ,  she  will  only  accept  an  ele¬ 
ment  as  being  a  member  of  that  type  according  to  the 
probability  associated  with  that  type. 

An  example  of  a  type  under  the  control  of  an  in¬ 
truder  would  be  a  nonce  generated  by  the  intruder,  per¬ 
haps  while  impersonating  someone  else.  An  example 
of  a  probabilistic  type  that  is  not  under  the  control  of  A 
would  be  a  nonce  generated  by  another  principal  B  and 


sent  to  A  in  a  message.  An  example  of  a  probabilistic 
type  that  is  also  under  the  control  of  A  would  be  a  nonce 
generated  by  A  and  sent  by  A  in  a  message,  or  received 
by  A  in  some  later  message. 

Definition  3.4  Let  X  and  Y  be  two  types.  We  say  that 
X  n  Y  holds  if  an  intruder  can  force  a  protocol  to  pro¬ 
duce  an  element  x  of  X  that  is  also  an  element  ofY . 

Of  course,  we  are  actually  interested  in  the  probabil¬ 
ity  that  X  n  V  holds.  Although  the  means  for  calculating 
P( X  n  Y)  may  vary,  we  note  that  the  following  holds  if 
there  are  no  other  constraints  on  X  and  Y: 

1 .  If  X  and  Y  are  both  under  the  control  of  the  in¬ 
truder,  then  P( X  n  Y)  is  1  if  X  fl  Y  f  <f>  and  is 
zero  otherwise; 

2.  If  X  is  under  the  control  of  the  intruder,  and  Y  is  a 
type  under  the  control  of  A.  and  the  intruder  knows 
the  value  of  the  member  of  Y  before  choosing  the 
member  of  A",  then  P(Y  n  X)  =  P(x  G  X  fl  Y), 
where  x  is  the  random  variable  associated  with  X ; 

3.  If  X  a  type  under  the  control  of  A,  and  T'  is  a 
type  local  to  B  but  not  under  the  control  of  B ,  then 

P( X  n  Y)  =  P(x  G  A  fl  Y); 

4.  If  X  is  under  the  control  of  A  and  Y  is  under  the 
control  of  some  other  (non-intruder)  B ,  then  P(T'n 
X)  =  P(x  =  y)  where  x  is  the  random  variable 
associated  with  X,  and  y  is  the  random  variable 
associated  with  Y. 

Now  that  we  have  a  notion  of  type  for  fields,  we  ex¬ 
tend  it  to  a  notion  of  type  for  messages. 

Definition  3.5  A  message  is  a  concatenation  of  one  or 
more  fields. 

Definition  3.6  A  message  type  is  a  function  IZfrom  lists 
of  fields  to  types,  such  that: 

1.  The  empty  list  is  in  Dom(7\l); 

2.  (xi,...,xu)  G  Dom(72.)  if  and  only  if 
{x\ , ...,  Xk-i)  G  Dom(72.)  and  xu  G 

1l((xi,...0k-i)); 

3.  If  {x\ , ...,  xf)  G  Dom(7?.),  and  Xu  =  i,  then 
1Z((xi  , ...,  Xk))  =  {(},  and ; 

4.  For  any  infinite  sequence  S  =  {...,X%t  ...)  such  that 
all  prefixes  of  S  are  in  Dom(1Z),  there  exists  an  n 
such  that,  for  ali  i  >  n,  Xi  =  i. 


The  second  part  of  the  definition  shows  how,  once  the 
first  k  —  1  fields  of  a  message  are  known,  then  1Z  can 
be  used  to  predict  the  type  of  the  k'th  field.  The  third 
and  fourth  parts  describe  the  use  of  the  empty  list  l  in 
indicating  message  termination.  The  third  part  says  that, 
if  the  message  terminates,  then  it  can’t  start  up  again. 
The  fourth  part  says  that  all  messages  must  be  finite. 
Note,  however,  that  it  does  not  require  that  messages 
be  of  bounded  length.  Thus,  for  example,  it  would  be 
possible  to  specify,  say,  a  message  type  that  consists  of 
an  unbounded  list  of  keys. 

The  idea  behind  this  definition  is  that  the  type  of  the 
n’th  field  of  a  message  may  depend  on  information  that 
has  gone  before,  but  exactly  where  this  information  goes 
may  depend  upon  the  exact  encoding  system  used.  For 
example,  in  the  tagging  system  in  [4],  the  type  is  given 
by  a  tag  that  precedes  the  field.  In  many  implementa¬ 
tions,  the  tag  will  consist  of  two  terms,  one  giving  the 
general  type  (e.g.  “nonce”),  and  the  other  giving  the 
length  of  the  field.  Other  implementations  may  use  this 
same  two-part  tag,  but  it  may  not  appear  right  before 
the  field;  for  example  in  ISAKMP,  and  hence  in  GDOI, 
the  tag  refers,  not  to  the  field  immediately  following  it, 
but  the  field  immediately  after  that.  However,  no  matter 
how  tagging  is  implemented,  we  believe  that  it  is  safe 
to  assume  that  any  information  about  the  type  of  a  field 
will  come  somewhere  before  the  field,  since  otherwise 
it  might  require  knowledge  about  the  field  that  only  the 
tag  can  supply  (such  as  where  the  field  ends)  in  order  to 
find  the  tag. 

Definition  3.7  The  support  of  a  message  type  1Z  is  the 
set  of  all  messages  of  the  form  aq||...||aqj  such  that 
(xi , ...,  xn)  G  Dom(7?.). 

For  an  example  of  a  message  type,  we  consider  a  mes¬ 
sage  of  the  form 

“nonce",  Aq ,  NONCE1 ,  “ nonce ",  N2 ,  NONCE2 
where  NONCEi  is  a  random  number  of  length  N\ 
generated  by  the  creator  of  the  message,  Aq  is  a  16-bit 
integer,  and  NONCE2  is  a  random  number  of  length 
TVo,  where  both  NONCE2  and  N2  are  generated  by 
the  intended  receiver,  and  N2  is  another  16-bit  integer. 
From  the  point  of  view  of  the  generator  of  the  message, 
the  message  type  is  as  follows; 

1.  TZ(Q)  =  “nonce". 

2.  TZ(  (“nonce"))  =  { X\length(X )  =  16}.  Since 
Aq  is  generated  by  the  sender,  it  is  a  type  under  the 
control  of  the  sender  consisting  of  the  set  of  16-bit 
integers,  with  a  certain  probability  attached. 


3.  1Z((“nonce"  ,Aq))  =  {_Y|  length(X)  =  Aq}. 
Again,  this  is  a  private  type  consisting  of  the  set 
of  fields  of  length  Aq  .  In  this  case,  we  can  choose 
the  probability  distribution  to  be  the  uniform  one. 

4.  7\  ((“n on ce" ,  X\.  A O.XC /•.' i )  I  =  {“nonce"}. 

5.  7Z(( “nonce" ,  Aq ,  NONCE1 ,  “nonce")) 
{X\length(X)  =  16}.  Since  the  sender  did  not 
actually  generate  Aq,  all  he  can  do  is  check  that 
it  is  of  the  proper  length,  16.  Thus,  this  type  is 
not  under  the  control  of  the  sender.  If  Aq  was  not 
authenticated,  then  it  is  under  the  control  of  the 
intruder. 

6.  7Z((“nonce" ,  Aq ,  NONCEi,  “nonce" ,  N2))  = 

{Y\length(Y)  =  Aq}.  Again,  this  value  is  not 
under  the  control  of  the  sender,  all  the  principal 
can  do  is  check  that  what  purports  to  be  a  nonce 
is  indeed  of  the  appropriate  length. 

7.  TZ(( “nonce" ,  Aq ,  NONCE1 ,  “nonce" ,  Aq , 
NONCEi,))  =  {(}  .  This  last  tells  us  that  the 
message  ends  here. 

From  the  point  of  view  of  the  receiver  of  the  message, 
the  message  type  will  be  somewhat  different.  The  last 
two  fields,  Aq  and  NONCE2  will  be  types  under  the 
control  of  the  receiver,  while  Aq  and  NONCEi  will 
be  types  not  under  its  control,  and  perhaps  under  the 
control  of  the  intruder,  whose  only  checkable  property 
is  their  length.  This  motivates  the  following  definition: 

Definition  3.8  A  message  type  local  to  a  principal  P  is 
a  message  type  7 Z  whose  range  is  made  up  of  types  local 
to  P. 

We  are  now  in  a  position  to  define  type  confusion. 

Definition  3.9  Let  7 Z  and  S  be  two  message  types.  We 
say  that  a  pair  of  sequences  {aq, ... ,xn )  G  Dom(TZ) 
and  (yi , . ...  y„)  G  Dom(S)  is  a  type  confusion  between 
1Z  and  S  if: 

1.  i  G  7Z((xi  t...,xn)); 

2.  l  G  S{(yi,...,ym)),  and; 

3.  aq||...||aq,  =  yi\\.-\\ym. 

The  first  two  conditions  say  that  the  sequences  de¬ 
scribe  complete  messages.  That  last  conditions  says  that 
the  messages,  considered  as  bit-strings,  are  identical. 


Definition  3.10  Let  TZ  and  S  be  two  message  types.  We 
say  that  TZ  n  S  holds  if  an  intruder  is  able  to  force  a 
protocol  to  produce  an  x  in  Dom(TZ )  such  that  there 
exists  y  in  Dom(S)  such  that  ( x .  y)  is  a  type  confusion.. 

Again,  what  we  are  interested  in  is  computing,  or  at 
least  estimating,  P(lZ\lS).  This  will  be  done  in  Section 
5. 

4  Constructing  and  Rearranging 
Message  Types 

In  order  to  perform  our  comparison  procedure,  we  will 
need  the  ability  to  build  up  and  tear  down  message 
types,  and  create  new  message  types  out  of  old.  In  this 
section  we  describe  the  various  ways  that  we  can  do  this. 

We  begin  by  defining  functions  that  are  restrictions  of 
message  types  (in  particular  to  prefixes  and  postfixes  of 
tuples). 

Definition  4.1  An  n-postfix  message  type  is  a  function 
TZfrom  tuples  of  length  n  or  greater  to  types  such  that: 

1.  For  all  k  >  0,  (x\ , ...,  xn+k)  G  Dom(72.)  if  and 
only  if  xn+k  G  U({xi ,  ...,Xn+k-i)); 

2.  If  (. vi,  ...,xn+k)  G  Dom(7\,),  and. xn+k  =  L  then 
TZ((x i,...,xn+k+1))  =  {(},  and; 

3.  For  any  infinite  sequence  S  =  (...,  x*, ...)  such 
that  all  prefixes  of  S  of  length  n  and  greater  are 
in  Dom(TZ),  there  exists  an  m  such  that ,  for  all 
i  >  m,  Xi  =  l. 

We  note  that  the  restriction  of  a  message  type  TZ  to 
sequences  of  length  n  or  greater  is  an  n-postfix  mes¬ 
sage  type,  and  that  a  message  type  is  a  0-postfix  message 
type. 

Definition  4.2  An  n -prefix  message  type  is  a  function  TZ 
from  tuples  of  length  less  than  n  to  types  such  that: 

1.  7 Z  is  defined  over  the  empty  list; 

2.  For  all  k  <  n,  (x\,  ...,Xk)  G  Dom(72.)  if  and  only 
if  xu  G  7Z((xi,  ...,Xk-i)),  and; 

3.  If  k  <  n  —  1,  and  (x\,...,xu)  G  Dom(7?.),  and 
Xk  =  L,  then  TZ((x xk+i})  =  {(}. 

We  note  that  the  restriction  of  a  message  type  to  se¬ 
quences  of  length  less  than  n  is  an  //-prefix  message 
type. 


Definition  4.3  We  say  that  a  message  type  or  n-prefix 
message  type  TZ  is  t-bounded  ifTZ(x)  =  i  for  all  tuples 
x  of  length  t  or  greater. 

In  particular,  a  message  type  that  is  both  t-bounded 
and  t-postfix  will  be  a  trivial  message  type. 

Definition  4.4  Let  TZ  be  an  n-postfix  message  type.  Let 
X  be  a  set  of  m-tuples  in  the  pre-image  ofTZ,  where  m 
>  n.  Then  TZ\_X  is  defined  to  be  the  restriction  of  R  to 
the  set  of  all  (x  \ ,  ...,<cm,  ...,xr)  in  DomflZ)  such  that 
{ Xl  i — 5  xm )  G  A . 

Definition  4.5  Let  TZ  be  an  n-prefix  message  type.  Let 
X  be  a  set  of  n-1  tuples.  Then  TZ\X  is  defined  to 
be  the  restriction  of  TZ  to  the  set  of  all  tuples  x  such 
that  x  G  X,  or  x  =  (./-|  •  -••''/  )  such  that  there  exists 
(Vi+U-'*etVn-i)  such  that  (m,  ...Xi,yi+1,  ...,y}l-i)  G 
X. 

Definition  4.6  Let  TZ  be  an  n-postfix  message  type. 
Then  Split(TZ)  is  the  function  whose  domain  is  the 
set  of  all  (x\ , . . . ,  x„ ,  yi ,  y-2 ,  xn+2 ,...,  xm)  of  length  n+1 
or  greater  such  that  (x\,  ...,;rn,t/i|||/2,.xn+2,  G 

Dcmi(TZ)  and  such  that 

a.  For  the  tuples  of  length  i  >  n  +1, 

Split(TZ){(x1,...,Xn,y1,y2,xn+2,  •••, Xm))  = 

TZ((x1,  ...,xn,y1\\y2,xn+2,  ...,xm)),  and; 

b.  For  tuples  of  length  n  +1 

Split(TZ)((y1,...,yn+1))  =  {z  \ 

{yi,-,yn+i\\z)  G  Dom(TZ). 

Definition  4.7  Let  TZ  be  an  n-prefix  message  type.  Let 
F  be  a  function  from  a  set  of  n-tuples  to  types  such  that 
there  is  at  least  one  tuple  (:r,+i ...,  xn)  in  the  domain  of 
F  such  that  (xi+i ...,  xn-\)  is  in  the  domain  ofTZ.  Then 
1Z$F,  the  extension  of  TZ  by  F,  is  the  function  whose 
domain  is 

a.  For  i  <  n,  the  set  of  all  (xi....,xf)  such  that 
{x\....,Xi)  G  Dorn(TZ),  and  such  that  there  exists 
{xi+ i...,xn)  such  that  {x\ ....,  x.i,  Xi+i ...,  xn)  G 
Dom{F); 

b  For  i  =  n,  the  set  of  all  {x\....,xn-\,xn) 
such  that  (x\ ....,  xn-\)  G  Dom{TZ)  and 
{.Ti ....,  xn-i ,  xn)  G  Dmn(F); 

and  whose  restriction  to  tuples  of  length  less  than  n  is 
TZ,  and  whose  restriction  to  n-tuples  is  F. 

Proposition  4.1  IfTZ  is  an  n-postfix  message  type,  then 
TZ  [.A  is  an  m-postfix  message  type  for  any  set  of  m- 
tuples  X,  and  Split  (TZ)  is  an  (n+1  (-postfix  message 


type.  If  TZ  is  t-bounded,  then  so  is  TZ\X,  while  Split  (TZ) 
is  (t+l)-bounded.  Moreover,  if  S  is  an  n -prefix  message 
type,  then  so  is  S\Y  for  any  set  ofn-1  tuples  Y,  and 
S§F  is  an  (n+1  )-prefix  message  type  for  any  function  F 
from  n-tuples  to  types  such  at  for  at  least  one  element 
(xj,- \.\...,xn)  in  the  domain  of  F,  (xj+i xn-\)  is  in 
the  domain  ofS. 

We  close  with  one  final  definition. 

Definition  4.8  Let  F  be  a  function  from  k-tuples  of 
fields  to  types.  We  define  Pre(F)  to  be  the  function 
from  k-tuples  of  fields  to  types  defined  by  Pre(F)(x ) 
is  the  set  of  all  prefixes  of  all  elements  of  F(x). 

5  The  Zipper:  A  Procedure  for 
Comparing  Message  Types 

We  now  can  define  our  procedure  for  determining 
whether  or  not  type  confusion  is  possible  between  two 
message  types  TZ  and  S ,  that  is,  whether  it  is  possible 
for  a  verifier  to  mistake  a  message  of  type  TZ  generated 
by  some  principal  for  a  message  of  type  S  generated  by 
that  same  principal  ,  where  TZ  is  a  message  type  local 
to  the  generator,  and  S  is  a  message  type  local  to  the 
verifier.  But,  in  order  for  this  to  occur,  the  probability 
of  TZ  n  S  must  be  nontrivial.  For  example,  consider  a 
case  in  which  TZ  is  a  type  local  to  and  under  the  control 
of  Alice  consisting  of  a  random  variable  64  bits  long, 
and  S  consists  of  another  random  64-bit  variable  local 
to  and  under  the  control  of  Bob.  It  is  possible  that  TZ  n  S 
holds,  but  the  probability  that  this  is  so  is  only  1  / 264 .  On 
the  other  hand,  if  TZ  is  under  the  control  of  the  intruder, 
then  the  probability  that  their  support  is  non-empty  is 
one.  Thus,  we  need  to  choose  a  threshold  probability, 
such  that  we  consider  a  type  confusion  whose  probabil¬ 
ity  falls  below  the  threshold  to  be  of  negligible  conse¬ 
quence. 

Once  we  have  chosen  a  threshold  probability,  our 
strategy  will  be  to  construct  a  “zipper”between  the  two 
message  types  to  determine  their  common  support.  We 
will  begin  by  finding  the  first  type  of  TZ  and  the  first  type 
of  S,  and  look  for  their  intersection.  Once  we  have  done 
this,  for  each  element  in  the  common  support,  we  will 
look  for  the  intersection  of  the  next  two  possible  types 
of  TZ  and  S,  respectively,  and  so  on.  Our  search  will 
be  complicated,  however,  by  the  fact  that  the  matchup 
may  not  be  between  types,  but  between  pieces  of  types. 
Thus,  for  example,  elements  of  the  first  type  of  TZ.  may 
be  identical  to  the  prefixes  of  elements  of  the  first  type 
of  S,  while  the  remainders  of  these  elements  may  be 


identical  to  elements  of  the  second  type  of  TZ,  and  so 
forth.  So  we  will  need  to  take  into  account  three  cases: 
the  first,  where  two  types  have  a  nonempty  intersection, 
the  second,  where  a  type  from  TZ  (or  a  set  of  remainders 
of  types  from  TZ)  has  a  nonempty  intersection  with  a 
set  of  prefixes  from  the  second  type  of  S,  and  the  third, 
where  a  type  from  S  (or  a  set  of  remainders  of  types 
from  S)  has  a  nonempty  intersection  with  a  set  of  pre¬ 
fixes  from  the  second  type  of  TZ.  All  of  these  will  im¬ 
pose  a  constraint  on  the  relative  lengths  of  the  elements 
of  the  types  from  S  and  TZ,  which  need  to  be  taken  into 
account,  since  some  conditions  on  lengths  may  be  more 
likely  to  be  satisfied  than  others. 

Our  plan  is  to  construct  our  zipper  by  use  of  a  tree  in 
which  each  node  has  up  to  three  possible  child  nodes, 
corresponding  to  the  three  possibilities  given  above.  Let 
TZ  and  S  be  two  message  types,  and  let  p  be  a  number 
between  1  and  0,  such  that  we  are  attempting  to  deter¬ 
mine  whether  the  probability  of  constructing  a  type  con¬ 
fusion  between  TZ.  and  S  is  greater  than  p.  We  define  a 
tertiary  tree  of  sept-tuples  as  follows.  The  first  entry  of 
each  sept-tuple  is  a  set  U  of  triples  (x,  y,  z ),  where  x  is 
a  bit-string  and  y  =  {y1,  ...,y„)  and  z  =  (zj,...,zm) 
such  that  j/l||...||j/n  =  ~i 1 1 •••! \zm  =  x.  We  will  call 
U  the  support  of  the  node.  The  second  and  third  en¬ 
tries  are  n  and  m  postfix  message  types,  respectively. 
The  fourth  and  fifth  are  message  types  or  prefix  mes¬ 
sage  types.  The  sixth  is  a  probability  q.  The  seventh  is 
a  set  of  constraints  on  lengths  of  types.  The  root  of  the 
tree  is  of  the  form  (</>,  TZ,  S,  {),{),  1,  D),  where  D  is  the 
set  of  length  constraints  introduced  by  TZ  and  S. 

Given  a  node,  (U.  Ti,  X,  J,  /C,  q,  C),  we  construct  up 
to  three  child  nodes  as  follows: 

1.  The  first  node  corresponds  to  the  case  in  which  a 
term  from  H  can  be  confused  with  a  term  from 
I.  Let  T  be  the  set  of  all  { x,y,z )  G  U  such  that 
P(H(y)  fl  T(z)  f  <j>)  ■  q  >  p.  Then,  if  T  is  non¬ 
empty,  we  construct  a  child  node  as  follows: 

a.  The  first  element  of  the  new  tuple  is  the  set 
T'  of  all  (x'.y'.z1)  such  that  there  exists 
(x,y,z)  G  T  such  that  x'  =  x\\y\,  where 
i/i  G  U„{y),  y'  =  appendfiy,  (</i)),  and 
z'  =  append) z,  (yi))\ 

Note  that,  by  definition  y\  is  an  element  of 
I(z)  as  well  as  Ti(y). 

b.  The  second  element  is  the  (n+l)-postfix 
message  type  'H  \Wr,  where  Wr  = 
{/,'  (T'.y',z')  G  /  '}: 

c.  The  third  element  is  the  (m+1)- 
postfix  message  type  l[Ws,  where 


Ws  =  {z'\(x',y',z')  £f}; 

d.  The  fourth  element  is  (J$Tln)  \Vr,  where 
Vr  =  {y\(x,y,z}  G  !}; 

e.  The  fifth  element  is  )/C(t!m)  [ \fs ,  where  \f  = 
{z\(xsy,z)  G  T}; 

f.  The  sixth  element  is  max{{P (TLn(y)  fl 
Im(z)  ±  4>  I  3xs.t.(x,y,z)  G  T)})  •  q,  and; 

g.  The  seventh  element  is  C  U  {ci},  where  ci  is 
the  constraint  length(77„)  =  length)!,,). 

We  call  this  first  node  the  node  generated  by  the 
constraint  length (77„)  =  length(!m). 

2.  The  second  node  corresponds  to  the  case  in  which 
a  type  from  77  can  he  confused  wit  prefix  of  a  type 
from  X. 

Let  The  the  set  of  all  (x,  y,  z)  such  that  P(TLn(fj)  n 
Pre{Xm)(z))  ■  q  >  p.  Then,  if  T  is  non-empty,  we 
construct  a  child  node  as  follows: 

a.  The  first  element  of  the  new  tuple  is  the  set 
T'  of  all  (xfyfz1)  such  that  there  exists 
(x.  y,  z)  G  T  such  that  x'  =  x\\y\,  where 
Vi  G  n„{y),  y'  =  append(y.{y1)),  and 
z'  =  append (&  (//:)); 

Note  that,  in  this  case  y\  is  an  element  of 
Pre(Xm)(z ))  as  well. 

b.  The  second  element  is  the  (n+l)-postfix 

message  type  FL\Wr,  where  Wr  = 

{y'\(x',y',z')  Gf}; 

c.  The  third  element  is  the  m-postfix  mes¬ 
sage  type  Split(X)[Ws  ,  where  TT’s  = 
{~\{x',y',z')  G  T'}; 

d.  The  fourth  element  is  (JfHn)  \Vr,  where 
Vr  =  {y\(x,y,z)  G  !}; 

e.  The  fifth  element  is  (K,$Pre(Im))\Vs, 

where  Vs  =  y,  z)  G  !}; 

f.  The  sixth  element  of  the  tuple  is 

max({P(nn(y)  n  Pre(Xm)(z )  | 

3 xs.t.(x,y,  z)  G  T))})  •  q ,  and; 

g.  The  seventh  element  is  C  U  {ci},  where  c\  is 
the  constraint  length(77„)  <  length!!,,,). 

We  call  this  node  the  node  generated  by  the  con¬ 
straint  lengthen)  <  length)!,,,). 

3.  The  third  node  corresponds  to  the  case  in  which  a 
prefix  of  a  type  from  77  can  be  confused  with  a  type 
from  !. 

Let  T  be  the  set  of  all  ( x,y,z )  in  U such  that 
P(Pre(77„)(i/)  n  X(z))  ■  q  >  p.  Then,  if  T  is 
nonempty,  we  construct  a  child  node  as  follows: 


a.  The  first  element  of  the  new  tuple  is  the  set 
T'  of  all  (x'sy'.z1)  such  that  there  exists 
(x.  y,  z)  G  T  such  that  x'  =  x\\y\,  where 
Vi  G  Pre(n„)(y),  y'  =  append(y,  (t/r)), 
and  z!  =  append{z,  (y i); 

Note  that,  in  this  case  y\  is  an  element  Im  (z) 
as  well. 

b.  The  second  element  is  the  n-postfix  mes¬ 
sage  type  Split{T-L)  \Wr,  where  Wr  = 
{y'\(x',y',z>)eT}-, 

c.  The  third  element  is  the  (m+l)-postfix 
message  type  !  Lli’s  ,  where  TT’s  = 
{z'\(x',y',z')  Gf}; 

d.  The  fourth  element  is  (t!|Pre(77„)))  \Vr, 
where  VR  =  {y\(x.y,z)  G  T}; 

e.  The  fifth  element  is  (/Ct)!,„)  [T’s,  where  Vs  = 
{z\(x,y,z}  G  !}; 

f.  The  sixth  element  is  max({P(Pre(T-Ln)(y)  n 
lm(z))  |  3 xs.t.{x,y,z)  G  !)})  •  q,  and; 

g.  The  seventh  element  is  C  U  {ci},  where  c\  is 
the  constraint  length (77 „)  >  length)!,,,). 

We  call  this  node  the  node  generated  by  the  con¬ 
straint  length(77„)  >  length)!,,,). 

The  idea  behind  the  nodes  in  the  tree  is  as  follows. 
The  first  entry  in  the  sept-tuple  corresponds  to  the  part 
of  the  zipper  that  we  have  found  so  far.  The  second  and 
third  corresponds  to  the  portions  of  1Z  and  S  that  are 
still  to  be  compared.  The  fourth  and  fifth  correspond  to 
the  portions  of  TZ  and  S  that  we  have  compared  so  far. 
The  sixth  entry  gives  an  upper  bound  on  the  probabil¬ 
ity  that  this  portion  of  the  zipper  can  be  constructed  by 
an  attacker.  The  seventh  entry  gives  the  constraints  on 
lengths  of  fields  that  are  satisfied  by  this  portion  of  the 
zipper. 

Definition  5.1  We  say  that  a  zipper  succeeds  if  it  con¬ 
tains  a  node  (If  {),  {),  ff,  1C,  q,  C). 

Theorem  5.1  The  zipper  terminates  for  bounded  mes¬ 
sage  types,  and,  whether  or  not  it  terminates,  it  succeeds 
if  there  are  any  type  confusions  of  probability  greater 
than  p.  For  bounded  message  types,  the  complexity  is 
exponential  in  the  number  of  message  fields. 

6  An  Example:  An  Analysis  of 
GDOI 

In  this  section  we  give  a  partial  analysis  of  the  signed 
messages  of  a  simplified  version  of  the  GDOI  protocol. 


There  are  actually  three  such  messages.  They  are:  the 
POP  signed  by  the  group  member,  the  POP  signed  by 
the  GCKS,  and  the  Group  key  Push  Message  signed  by 
the  GCKS.  We  will  show  how  the  POP  signed  by  the 
GCKS  can  be  confused  with  the  Groupkey  Push  Mes¬ 
sage. 

The  POP  is  of  the  form  NONCEA,NONCEB 
where  NONCE/ 1  is  a  random  number  generated  by 
a  group  member,  and  NONC  EB  is  a  random  number 
generated  by  the  GCKS.  The  lengths  of  NONCEa  and 
NONC Eb  are  not  constrained  by  the  protocol.  Since 
we  are  interested  in  the  types  local  to  the  GCKS,  we 
have  NONCEa  the  type  consisting  of  all  numbers,  and 
NONC Eb  the  type  local  to  the  GCKS  consisting  of  the 
the  single  nonce  generated  by  the  GCKS. 

We  can  thus  define  the  POP  as  a  message  type  local 
to  the  GCKS  as  follows: 

1.  U(  ())  =  NONCEa  where  NONC EA  is  the 
type  under  the  control  of  the  intruder  consisting  of 
all  numbers,  and; 

2.  =  NONCEb  where  NONCEb  is  a 
type  under  control  of  the  GCKS. 

We  next  give  a  simplified  (for  the  purpose  of  expo¬ 
sition)  Groupkey  Push  Message.  We  describe  a  version 
that  consists  only  of  the  Header  and  the  Key  Download 
Payload: 

NONC EH M,  MESSAGE-LENGTH ,  sig, 
KDLENGTH,  KDHEADER ,  KEYS 

The  NONC  Eh  at  the  beginning  of  the  header  is 
of  fixed  length  (16  bytes).  The  one-byte  kd  field 
gives  the  type  of  the  first  payload,  while  the  4-byte 
M  ESS  AGE-LENGTH  gives  the  length  of  the  mes¬ 
sage  in  bytes.  The  one-byte  sig  field  gives  the  type 
of  the  next  payload  (in  this  case  the  signature,  which 
is  not  part  of  the  signed  message),  while  the  2-byte 
KDLENGTH  gives  the  length  of  the  key  download 
payload.  We  divide  the  key  download  data  into  two 
parts,  a  header  which  gives  information  about  the  keys, 
and  the  key  data,  which  is  random  and  controlled  by  the 
GCKS.  (This  last  is  greatly  simplified  from  the  actual 
GDOI  specification). 

We  can  thus  define  the  Groupkey  Push  Message  as  the 
following  message  type  local  to  the  intended  receiver: 

1.  5(())  =  NONC Eh  where  NON CEH  is  the 
type  consisting  of  all  16-byte  numbers; 

2.  S((x i))  =  {kd}; 

3.  5((.Ti,a;o))  =  MESSAGE-LENGTH,  where 
LIES  SAGE-LENGTH  is  the  type  consisting  of 
all  4-byte  numbers; 


4.  S((x  1,x-2,x3))  =  {sig}; 

5.  S((x i,X2,X3,X4))  =  KDLENGTH ,  where 
KDLENGTH  is  the  type  consisting  of  all  2-byte 
numbers; 

6.  S((x i,.T2,.T3, £4,2:5))  =  KDHEADER,  where 
the  type  KDHEADER  consists  of  all  possi¬ 
ble  KD  headers  whose  length  is  less  than  x-;>  — 
length(;ri  |  |x2 1 \x% \\x±  |  |;r.g)  and  the  value  of  x&. 

7.  S((xi,X2,X3,X4,X5,xq))  =  KEYS,  where 

KEYS  is  the  set  of  all  numbers  whose  length  is 
less  than  X3  —  lengthen  |  |xo  1 1*3 1 \x±  \ \x$  |  |:cg)  and 
equal  to  x&  —  length(xg).  Note  that  the  second 
constraint  makes  the  first  redundant. 

All  of  the  above  types  are  local  to  the  receiver,  but 
under  the  control  of  the  sender. 

We  begin  by  creating  the  first  three  child  nodes. 
All  three  cases  length(yi)  =  length(xi),  length(yi)  < 
length (.r- 1 ),  and  length)?;] )  >  length(xi),  are  non-trivial, 
since  x  1  £  NONC  Eh  is  an  arbitrary  16-byte  number, 
and  yi  £  NONCEa  is  a  completely  arbitrary  num¬ 
ber.  Hence  the  probability  of  NONCEa  n  NONC EB 
is  one  in  all  cases.  But  let’s  look  at  the  children  of 
these  nodes.  For  the  node  corresponding  to  length)?/ 1 ) 
=  length):/-] ),  we  need  to  compare  x->  and  r/o.  The  term 
x-2  is  the  payload  identifier  corresponding  to  “kd".  It 
is  one  byte  long.  The  term  y  >  is  the  random  nonce 
NONCEb  generated  by  the  GCKS.  Since  y->  is  the 
last  field  in  the  POP,  there  is  only  one  possibility; 
that  is,  length);/^)  <  length)?/^).  But  this  would  re¬ 
quire  a  member  of  Pre{N ON C EB)  to  be  equal  to 
“kd".  Since  NONC EB  is  local  to  the  GCKS  and  un¬ 
der  its  control,  the  chance  of  this  is  1/28.  If  this  is 
not  too  small  to  worry  about,  we  construct  the  child 
of  this  node.  Again,  there  will  be  only  one,  and  it 
will  correspond  to  lcngth(:r:; )  <  length)^)  -  length)^)- 
In  this  case,  x;>  is  the  apparently  arbitrary  number 
MESSAGE-LENGTH.  But  there  is  a  nontriv¬ 
ial  relationship  between  M  ESS  AGE  -LEN  GTH  and 
NONCEb,  in  that  MESSAGE-LENGTH  must  de¬ 
scribe  a  length  equal  to  M  +  N,  where  M  is  the  length 
of  the  part  of  NONC  Eg  remaining  after  the  point  at 
which  MESSAGE-LENGTH  appears  in  it,  and  N 
describes  the  length  of  the  signature  payload.  Since  both 
of  these  lengths  are  outside  of  the  intruder’s  control,  the 
probability  that  the  first  part  of  NONCEb  will  have 
exactly  this  value  is  1/216.  We  are  now  up  to  a  proba¬ 
bility  of  1/224. 

When  we  go  to  the  next  child  node,  again  the  only 
possibility  is  length^)  <  length)?^)  -  length (:r'3 )  - 


length(;co),  and  the  comparison  in  this  case  is  with  the 
1-byte  representation  of  “sig”.  The  probability  of  type 
confusion  now  becomes  1/232.  If  this  is  still  a  concern, 
we  can  continue  in  this  fashion,  comparing  pieces  of 
NONC Eg  with  the  components  of  the  Groupkey  Push 
Message  until  the  risk  has  been  reduced  to  an  accept¬ 
able  level.  A  similar  line  of  reasoning  works  for  the 
case  Icngthff/i )  <  length (;/•  | ). 

We  now  look  at  the  case  length(r/i)  >  Icngtht.r  [ ),  and 
show  how  it  can  be  used  to  construct  the  attack  we  men¬ 
tioned  at  the  beginning  of  this  paper.  We  concentrate 
on  the  child  node  generated  by  the  constraint  length!?;] ) 
-  length(.'Ci)  >  lengthl.To).  Since  y \  G  NONCEa 
is  an  arbitrary  number,  the  probability  that  xo  can  be 
taken  for  a  piece  of  y\ ,  given  the  length  constraint,  is 
one.  We  continue  in  this  fashion,  until  we  come  to  the 
node  generated  by  the  constraint  length^)  <length(?/  i ) 
The  remaining  field  of  the  Groupkey  Pull 
Message,  x-  C  KEYS  is  an  arbitrary  number,  so  the 
chance  that  the  remaining  field  of  the  POP,  y->  together 
with  what  remains  of  yi,  can  be  mistaken  for  x-?,  is  one, 
since  the  concatenation  of  the  remains  of  y  i  with  yn,  by 
definition,  will  be  a  member  of  the  abitrary  set  KEYS. 

7  Conclusion  and  Discussion 

We  have  developed  a  procedure  for  determining  whether 
or  not  type  confusions  are  possible  in  signed  messages 
in  a  cryptographic  protocol.  Our  approach  has  certain 
advantages  over  previous  applications  of  formal  meth¬ 
ods  to  type  confusion;  we  can  take  into  account  the  pos¬ 
sibility  that  an  attacker  could  cause  pieces  of  message 
fields  to  be  confused  with  each  other,  as  well  as  entire 
fields.  It  also  takes  into  account  the  probability  of  an  at¬ 
tack  succeeding.  Thus,  for  example,  it  would  catch  mes¬ 
sage  type  attacks  in  which  typing  tags,  although  present, 
are  so  short  that  it  is  possible  to  generate  them  randomly 
with  a  non-trivial  probability. 

Our  greater  generality  comes  at  a  cost,  however.  Our 
procedure  is  not  guaranteed  to  terminate  for  unbounded 
message  types,  and  even  for  bounded  types  it  is  expo¬ 
nential  in  the  number  of  message  fields.  Thus,  it  would 
have  not  have  terminated  for  the  actual,  unsimplified, 
GDOI  protocol,  which  allows  an  arbitrary  number  of 
keys  in  the  Key  Download  payload,  although  it  still 
would  have  found  the  type  confusion  attacks  that  we  de¬ 
scribed  at  the  beginning  of  this  paper. 

Also,  we  have  left  open  the  problem  of  how  the 
probabilities  are  actually  computed,  although  in  many 
cases,  such  as  that  of  determining  whether  or  not 
a  random  number  can  be  mistaken  for  a  format¬ 


ted  field,  this  is  fairly  straightforward.  In  other 
cases,  as  in  the  comparison  between  NONCEb  and 
M  ESS  AGE. LENGTH  from  above,  things  may  be 
more  tricky.  This  is  because,  even  though  the  type  of 
a  field  is  a  function  of  the  fields  that  come  before  it 
in  a  message,  the  values  of  the  fields  that  come  after  it 
may  also  act  as  a  constraint,  as  the  length  of  the  part  of 
the  message  appearing  after  MESSAGE  JLENGTH 
does  on  the  value  of  MESS  AGE. LENGTH. 

Other  subtleties  may  arise  from  the  fact  that  other 
information  that  may  or  may  not  be  available  to 
the  intruder  may  affect  the  probability  of  type  con¬ 
fusion.  For  example,  in  the  comparison  between 
MESSAGE.LENGTH  and  NONC EB,  the  in¬ 
truder  has  to  generate  NONCEa  before  it  sees 
NONCEb-  If  it  could  generate  NONCEa  after  it 
saw  NONCEb ,  this  would  give  it  some  more  con¬ 
trol  over  the  placement  of  MESSAGEMENGTH 
with  respeett  to  NONCEb ■  This  would  in¬ 
crease  the  likelyhood  that  it  would  be  able  to  force 
MESS  AGE. LENGTH  to  have  the  appropriate 
value. 

But,  although  we  will  need  to  deal  with  special  cases 
like  these,  we  believe  that,  in  practice,  the  number  of  dif¬ 
ferent  types  of  such  special  cases  will  be  small,  and  thus 
we  believe  that  it  should  be  possible  to  narrow  the  prob¬ 
lem  down  so  that  a  more  efficient  and  easily  automat¬ 
able  approach  becomes  possible.  In  particular,  a  study 
of  the  most  popular  approaches  to  formatting  crypto¬ 
graphic  protocols  should  yield  some  insights  here. 
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